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(57) Abstract 
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identifier and transaction amount from a customer mobUe station (60). The TSN (30) sends a transaction verification request message 
to both the customer mobile station (60) and the merchant terminal (70). Upon receipt of transaction verification, the TSN (30) requests 
transfer of the transaction amount from the customer account to the merchant accounL 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to tlie PCT on the front pages of pamphlets publishing international applications under the PCT.- 



AL 


Albania 


ES 


Spain 


LS 


Lesotho 


SI 


Slovenia 


AM 


Armenia 


FI 


Finland 


LT 


Lithuania 


SK 


Sbvakia 


AT 


Austria 


FR 


France 


LU 


Luxembourg 


SN 


Senegal 


AU 


Australia 


GA 


Gabon 


LV 


Latvia 


SZ 


Swaziland 


AZ 


Azerbaijan 


GB 


United Kingdom 


MC 


Monaco 


TD 


Chad 


BA 


Bosnia and Herzegoviaa 


G£ 


Georgia 


MD 


Republic of Moldova 


TG 


Togo 


BB 


Barbados 


GH 


Ghana 


MG 


Madagascar 


TJ 


Tajikistan 


BE 

BF — 


Belgium 

— BuiJcinaFaso 


GN 

— GR 


Guinea 


MK 


The former Yugoslav 


TM 


Turkmenistan 


Greece 




Republic of Macedonia 


TR 


Turkey 


BG 


Bulgaria 


HU 


Hungary 


ML 


MaU 


TT 


Trinidad and Tobago 


BJ 


Benin 


IE 


Ireland 


MN 


Mongolia 


UA 


Ukraine 


BR 


Brazil 


IL 


Israel 


MR 


Mauritania 


UG 


Uganda 


BY 


Belarus 


IS 


Iceland 


MW 


Malawi 


US 


United States of America 


CA 


Canada 


IT 


Italy 


MX 


Mexico 


uz 


Uzbekistan 


CF 


Central African Republic 


JP 


Japan 


NE 


Niger 


VN 


Viet Nam 


CG 


Congo 


KE 


Kenya 


NL 


Netheriands 


YU 


Yugoslavia 


CH 


Switzerland 


KG 


Kyrgyzstan 


NO 


Norway 


ZW 


Zimbabwe 


a 


C6te d'lvoire 


iCP 


Democratic People's 


NZ 


New Zealand 






CM 


Caracroon 




Republic of Korea 


PL 


Poland 






CN 


China 


KR 


Republic of Korea 


PT 


Portugal 






cu 


Cuba 


KZ 


Kazalcstan 


RO 


Roihania 






cz 


Czech Republic 


LC 


Saint Lucia 


RU 


Russian Federation 






DE 


Germany 


LI 


Liechtenstein 


SD 


Sudan 






DK 


Denmark 


LK 


Sri Lanka 


SE 


Sweden 






EE 


Estonia 


LR 


Liberia 


SG 


Singapore 







wo 98/47116 



PCT/SE98/00691 



1 

TELE/DATACOMMUNICATIONS PAYMENT 
METHOD AND APPARATUS 

^BACKGROUND 

This application claims the benefit of the following, both of 
5 which are incorporated herein by reference: ( I ) United States Provisional 
Patent Application No. 60/043,610 which was filed on April 15, 1997 by 
the same inventor bearing title TELE/DATACOMMUNICATIONS 
PAYMENT METHOD AND APPARATUS; (2) United States 
Provisional Patent Application No. 60/049,774 which was filed on June 16, 
10 1997 by the same inventor bearing title 

TELE/DATACOMMUNICATIONS PAYMENT METHOD AND 
APPARATUS. 



1. FIELD OF THE INVENTION 

This invention pertains to employment of telecommunications to 
15 facilitate financial transactions. 

2. RELATED ART AND OTHER CONSIDERATIONS 

Many consumer-based commercial tiansactions involve 
payment using a credit card or bank debit card. In the course of such 
transactions, a computerized "cash register" terminal or the like is 
20 connected by a telecommunications Imk to a fmancial institution (e.g., a 
bank or credit card company which sponsors the card) for the purpose of 
obtaining an authorization or indication that the consumer's account 
balance is sufficient to cover tiie cost of the particular transaction. In the 
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case of a bank debit card, the consumer's account is essentially 
immediately debited for the amount of the transaction, and the funds 
ultimately made available to the seller or provider of services. For a credit 
card, on the other hand, the consumer is subsequently mailed a bill 
requiring payment for the transaction. 

For consumers utilizing written checks, similar services are 
available for obtaining at least preliminary approval that the check will 
clear the bank upon which the check is drawn. 

The check, credit card, and debit card modes of payment 
require, of course, that the consumer physically posses the same at the time 
.of the transaction. Checks, credit cards, and debit cards are of no value if 
left at home or otherwise unavailable at the time of the transaction. 



Moreover, there are significant security risks involved with 
utilization of checks, credit cards, and debit cards. All are prone to being 
lost or stolen, and subsequently improperly used by third persons. A 
further risk is that imprints or copies of the cards may enable unauthorized 
20 use by a third person. 

What is needed, therefore, and an object of the present 
mvention, is a secure and efficient mode of payment for a financial 
transaction. 



25 BRIEF SUMMARY OF THE INVENTION 



A teie/datacommunications network has a service node (TSN) 
which facilitates payment/transfer fi-om a customer account of a customer 
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financial institution to a merchant account of a merchant financial 
institution. The TSN acquires a merchant identifier and transaction amount 
from a customer mobile station. The TSN sends a ti-ansaction verification 

request messag e to both the customer mobile station and the me rchant 

terminal. Upon receipt of ti-ansaction verification, tiie TSN requests 
ti^sfer of the ti^saction amount from the customer account to the 
merchant account. 

The TSN of the invention also optionally provides an 
autiiorization assurance feature and a security featiire. For authorization 
assurance, prior to requesting a funds transfer from the customer accountin 
the amount of tiie transaction amount, the TSN checks whetiier tiie 
customer financial institution will authorize such funds transfer. 



The ti-ansaction can occur in a variety of manners. In one 
mode of tiie invention, tiie ti-ansaction can occur while tiie customer is at 
tiie merchant's premises, whereat tiie customer acquires tiie merchant 
identifier and tiie tiansaction amount . In anotiier mode, tiie customer can 
be at a customer predetermined native location, e.g., at tiie customer's 
20 home or place of business, where tfie customer views a merchant's web 
page. The merchant's web page, in addition to providing ttie merchant 
identifier, provides eitiier an advertisement of an invoice (e.g., a utility bill). 

For the first mode of tiie invention, tiie security featiire of the 
25 invention enables tiie TSN to confirm tiiat tiie customer wireless 
communication unit (e.g., mobile station) is witiun a predetermined 
geographical proximity of tiie merchant terminal prior to requesting transfer 
of tiie h-ansaction amount from tiie customer account to tfie merchant 
account at tiie merchant financial institution. The TSN has access to 
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prestored GPS location coordinates of the merchant terminal, and receives 
the current GPS coordinates of the customer mobile station from the 
customer mobile station. The TSN compares the GPS location coordinates 
of the merchant terminal and the current GPS coordinates of customer 
5 mobile station to determine if the two are within an acceptable proximity 
range. 

For the second mode of the invention, the security feature of 
the invention enables the TSN to confirm diat the customer is in a customer 
1 0 predetermined native location at the time the customer authorizes payment 
to the merchant. For example, the geographical security feature would bar 
any purchases or payment initiated when (1) the mobile station is not 
connected to base station(s) used when the ovraer of the mobile station is at 
one of his customer predetermined native locations, or (2) when GPS 
coordinates of the mobile station are not within an acceptable proximity 
range of the customer predetermined native location. 

BRIEF DESC RIPTION OF THE DRAWTNOS 

- The foregoing and other objects, features, and advantages of the 
invention will be apparent from the following more particular description of 
preferred embodiments as illustrated in the accompanying drawings in 
which reference characters refer to the same parts throughout the various 
views. The drawings are not necessarily to scale, emphasis instead being 
placed upon illustrating the principles of the invention. 



Fig. 1 is a schematic view of a tele/datacommunications 
network including a node which provides a telepayment service accordmg 
to an embodiment of the invention. 



wo 98/47116 PCT/SE98/00691 



Fig. 1 A is a schematic view of a tele/datacommunications 
network including a node which provides a telepayment service according 
to another embodiment of the invention. 



5 Fig. IB is a schematic view of a tele/datacommunications 

network including a service control node of an intelligent network which 
provides a telepayment service according to an embodiment of the 
invention. 

Fig- 2 is a schematic view of the service control node 
included in the telecommunications network of Fig. I. 

fig- 2A(1) is a schematic view of the service control node 
included in the telecommunications network of Fig. 1 A for a fu^ mode of 
15 the invention. 



Fig. 2A(2) is a schematic view of the service control node 
included in the telecommunications network of Fig. 1 A for a second mode 
of the invention. 

20 

Fig. 3, is a schematic view showing the relationship of Fig. 
3A,Fig.3B,andFig.3C. 

Fig. 3A, Fig. 3B, and Fig. 3C are flowcharts showing steps 
25 executed by a service control node according to the invention. 

Fig. 4A is a flowchart showing additional steps executed by a 
service control node in connection with a security feature of a first mode of 
the invention. 
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Fig. 4B is a flowchart showing additional steps executed by a 
service control node in connection with a security feature of a second mode 
of the invention. 

5 

Fig. 5 A is a schematic view of a portion of Fig. 1, but 
depicting a customer at a merchant's premises. 

Fig. 5B is a schematic view of a portion of Fig. 1, but 
depicting a customer having a mobile station (in the form of a mobile 
telephone) and a workstation at a customer predetermined native location 
which is preferably remote from a merchant's premises. 

Fig. 5C is a schematic view of a portion of Fig. 1, but 
depicting a customer having a mobile station (in the form of a laptop 
computer with mobile termination capabilities), the mobile station situated 
at a customer predetermined native location which is preferably remote 
from a merchant's premises. 

DETAILED DESCRIPTTON OF THE PR AWTNr:s 

In the following description, for purposes of explanation and not 
limitation, specific details are set forth such as particular architectures, 
interfaces, techniques, etc. in order to provide a thorough understanding of 

.thepresentinv^^ 

art that the present invention may be practiced in other embodiments that 
depart from these specific details. In other instances, detailed descriptions 
of well known devices, circuits, and methods are omitted so as not to 
obscure the description of the present invention with unnecessary detail. 
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Fig. 1 shows a telecommunications network 20 having a 
special function node known as a telepay service node (TSN) 30. Telepay 
TSN 30 is connected to an exchange, such as transit exchange (TE) 40, of a 

public switched telephone network (PSTN) 50. PSTN 50 includes both 

landline and radio communications Imks. As such, PSTN 50 provides 
connections to a plurality of remote wireless units or mobile stations, of 
which customer mobile station 60 (e.g., a mobile telephone) is but one 
example, and via landlines to non-mobile units such as merchant terminal 
70. Although customer wireless communication unit 60 is hereinafter 
illustrated as being a mobile telephone, it should be understood that other 
types of devices are also contemplated for use with the invention, such as a 
personal digital assistant (PDA) with a radio connection to PSTN 50 or a 
computer with mobile termination capabilities. 

Customer mobile termmal 60 is served by base station (BS) 
52 in PSTN 50. Base station 52 is connected to a mobUe switching center 
(MSG) 54 which routes calls from the customer to telepay TSN 30. 

Fig. 1 shows telepay TSN 30 as also being connected by a 
20 , data network N to a customer financial institution 80 and a merchant 
financial institution 90. Although illustrated separately, it should be 
understood that network N can be included in PSTN 50. Moreover, a 
variety of protocols (e.g. X.25, X.21, leased line and TCP/IP, or 
internet/TCP/IP) can be utilized over network N. 



25 



While Fig. 5B and Fig. 5C show PSTN 50 and intemet 51 
directly connected together, the person skilled in the art will appreciate that 
such illustrations are a simplification for not obscuring salienfraspects of 
the invention. In reality, both data switched networks (such as intemet 51) 
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and circuit switched networks are connected via respective service or 
gateway nodes to mobile switching centers of a mobile telecommunications 
network. The mobile telecommunications network comprises not only the 
mobile stations, but base stations in radio conununications with the mobile 
5 stations, base station controllers (also known as radio network controllers) 
in conununication with the base stations, and with the mobile switching 
centers communicating with the base stations controllers. 

In accordance with the present invention, a customer who 
10 operates customer mobile station 60 seeks to purchase goods or services 
from a merchant. The merchant has merchant terminal 70 which functions 
as a computerized cash register and which has modem connection to PSTN 
50. The customer via customer mobile station 60 can make payment for the 
goods or services using telepay TSN 30, and particularly can transfer funds 
15 from the customer's account in customer financial mstitution 80 to the 
merchant's account in merchant financial institution 90. Customer 
financial institution 80 can be, for example, a banking institution with 
which the customer has an account or a credit card company with which the 
customer has an account. 

20 

-The present mvention permits financial transactions to occur 
in a variety of manners. Fig. 5A depicts a first mode of the invention, hi 
which the transaction occurs while the customer is at the merchant's 
premises 92A. At the merchant's premises 92A the customer acquires the 
25 — merchant-identifier-and-the-transaetion amountv"Fig-5B-ilte 

mode of the invention in which the customer is situated at a customer 
predetermined native location 62B, preferably remote from the merchant's 
premises 92B. The customer predetermined native location 62B can be, for 
example, the customer's home or place of business. In accordance with this 
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second mode, at the customer predetennined native location 62B the 
customer views a merchant's web page as displayed on a monitor 64B. The 
merchant's web page, in addition to providing the merchant identifier, 
provides either an advertisement of an mvoice (e.g., a utility bill). Fig. 5C 
5 illustrates a variation of the second mode of the invention in which mobile 
station 60 takes the form of a laptop computer with mobile termination. The 
mobile station of Fig. 5C is capable of having connections (through the 
mobile telecommunications network) both with the internet 5 1 and with 
PSTN 50. 

10 

In brief, suppose that the customer wants to pay $ 1 OOUS for a 
good or service, or for payment of a bill or invoice (such as a utility bill, for 
example^. In accordance with the present invention, the customer merely 
dials the directory number of the telepay TSN 30 (e.g. a A1-800" directory 

1 5 number) and, in response to prompts generated by telepay TSN 3 0, enters a 
merchant identifier and a transaction amount (SIOOUS). The merchant 
identifier is provided by the merchant (e.g., prominently displayed at the 
merchant's premises 92A [see Fig. 5A] or shown on the merchant's web 
page displayed on monitor 64B [see Fig. 5B] or laptop [see Fig. 5C]). The 

20 transaction amount is the total cost for the good or service or bill amount. 
Telepay TSN 30 sends a verification message to at least one, and preferably 
both, parties to the transaction. In this regard, telepay TSN 30 sends a 
verification message to the merchant, providing (e.g., on a cash register 
display) the transaction amount to be credited to the merchant's account 

25 and a transaction code. A similar verification message is sent to customer 
mobile station 60. If in agreement, both the customer and the merchant 
then send a verification message to telepay TSN 30. Telepay TSN 30 then 
arranges for the customer account to be debited, and the merchant account 
to be credited, by the transaction amount. 
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In the embodiment illustrated in Fig. 1, telepay TSN 30 is a 
special purpose node which includes general purpose computer 30C having 
a UNIX or Microsoft NT operating system and executes a set(s) of coded 
instructions for performing the actions herein described. Computer 30C is 
connected to an accessory or peripheral 30P and a data network interface 
30D. Peripheral 30? receives and interprets DTMF signalling of numbers 
(e.g., for transaction amount, merchant identifier, PIN), and also generates 
and transmits voice/sound prompts. Data network interface 30D is 
connected via data network N to customer financial institution 80 and to 
merchant financial institution 90. 

In pne embodiment of the invention, the set of instructions" 
and functions executed by telepay TSN 30 are modularized. In such 
embodiment, the modules of telepay TSN 30 as illustrated in Fig. 2 include 
customer communication module 202; merchant communication module 
204; transfer communication module 206; financial institution 
communication module 208; and, funds authorization module 210. 

Customer communication module 202 includes a customer 
communication interfece 202-1 which handles communication with 
customer mobile station 60 over PSTN 50. Also included in customer 
communication mode 202 are prompt generator interface 202-2, 
information collector interfece 202-3, verification unit 202-4, and 

SansactLonj;onfumation_unit.202=5.--Interface^ 

connected to peripheral 30P. 



Similarly, merchant communication module 204 includes a 
merchant communication interface 204-1 which handles communications 
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with merchant tenninal 70 over PSTN 50. Also included in merchant 
communication module 204 are prompt generator interface 204-2; 
verification unit 204-3; and, transaction confirmation unit 204-4. 



5 Transfer coordination module 206 includes a transaction 

record generator 206- 1 and a transaction code generator 206-2. Transaction 
record generator 206-1 is used to build records for transaction data base 
220. In addition to building transaction database 220^ transfer coordination 
module 206 searches for and accesses records stored in transaction database 
10 220. 

Financial institution communication module 208 includes 
customer fmancial institution includes customer financial institution 
interface 208- 1 and merchant financial institution interface 208-2. 
1 5 Financial institution communication module 208 also has a customer search 
engine 208-3 for searching a customer database 222 and a merchant search 
engme 208-4 for searching a merchant database 224. ' 

For the embodiment shown in Fig. 2, customer database 222 
!0 has prestored therein a record for each customer who subscribes to the 
telepay service offered by telepay TSN 30. The record for each customer 
has at least three fields, including a customer identifier field 222A; a 
customer financial institution address field 222B; and, a customer account 
identifier field 222C. The customer account identifier field 222C is the 
5 customer's account number for the particular financial institution whose 
address appears in field 222B. 

Similarly, the embodiment shown in Fig. 2, customer 
database 224 has prestored therein a record for each merchant who 
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participates in the telepay service offered by telepay TSN 30. The record 
for each merchant has at least three fields, including a merchant identifier 
field 224 A; a merchant financial institution address field 224B; and, a 
merchant account identifier field 224C. The merchant account identifier 
5 field 224C is the merchant's account number for the particular financial 
institution whose address appears in field 224B. 

While databases 220, 222, and 224 have been illustrated in 
Fig. 2 as being included in telepay TSN 30, it should be understood that 
1 0 such need not necessarily be the case. For example, in an alternate 

embodiment databases 220, 222, and 224 can be located remotely, e.g., at 
one or more special nodes such as, for example, service data points (SDPs) 
;Of an intelligent telecommunications network. 

'5 Actions performed by telepay TSN 30 are underetood as 

described in more detail in connection with Fig. 3 A, Fig. 3B, and Fig. 3C 
and with contextual reference to Fig. 1 . In the scenario briefly described 
above the customer and wants to pay $ 1 OOUS for a good or service. As 
depicted by event El in Fig. 1, the customer merely dials on customer 

20 mobile station 60 the directory number of the telepay TSN 30. The call is 
routed through PSTN 50, which includes mobile base station (BS) 52, and - 
via MSG 54 and SSP 40 to telepay TSN 30, as shown by event E2. At 
telepay TSN 30, upon initially handling the call customer communications, 
module 202 obtains a customer identifier (e.g., customer directory number) 

25 from the cd lsig nalin gjgjiich,s.ets_up_thexall-(see-stepJ00-in-F-ig.-3A-^^ 

Upon completion of the connection, customer 
communications module 202 directs peripheral 30C (via prompt generator 
interface 202-2) to issue a series of prompts which are transmitted over the 
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call connection to customer mobile station 60. The prompts, depicted as 
event E3 in Fig. 1, are preferably audible prompts and/or displayed text 
prompts which request either a DTMF response (e.g., for the customer to 
select digits on the telephone keyboard in response to the prompt) or a 

"~5 voice response. As indicated by step 302 of Fig. 3A, the series of prompts 
includes a fuxt prompt for entry of the merchant identifier and a second 
prompt for entry of the transaction amount. For security purposes, a third 
prompt for a customer personal identification number (PIN) may also be 
generated. All kinds of additional security functionality can be added either 
10 independently or additionally, such as cryptographic keys, fingerprint 
recognition at the mobile station, etc. Step 320 of Fig. 3 A also shows 
information collector 202-3 of customer conmiunication module 202 
obtaining the customer input in response to each of the prompts generated 
by prompt generator 202-2. In Fig. 1, customer input in response to the 

15 prompts is indicated as event E4. The customer input is processed by 
peripheral 30P. 

Upon collection of the information entered on customer 
mobile station 60 in response to the prompts of step 302, at step 304 the 

20 customer communication module 202 sends the information it has gleaned 
(as processed e.g. by the peripheral 30P) along with the customer identifier 
to transfer coordination module 206. Transaction record generator 206-1 of 
transfer coordination module 206 uses the information to build a record in 
transaction database 220 for the transaction (see step 304 of Fig. 3 A). In 

25 connection with building the record for the transaction, transaction record 
generator 206-1 requests and obtains firom transaction code generator 206-2 
a unique transaction code or identifier for the transaction. Thus far, 
therefore, the record for the call includes the unique transaction code, the 
customer identifier, the merchant identifier, and the transaction amount 
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At step 306, telepay TSN 30 determines the customer 
financial institution address and the customer account identifier at the 
customer financial institution. In particular, at step 306 the transfer 
coordination module 206 sends to the financial institution communication 
module 208 a signal which includes the current transaction code, the 
current customer identifier, and (optionally) the transaction amount. The 
current customer identifier included in this signal is used by customer 
search engine 208-3 to search customer data base 222. In particular, 
customer search engine 208-3 locates a record in data base 222 having the 
customer identifier in field 222A, and obtains the customer financial 
institution address and customer account identifier fi*om fields 222B and 
222C, respectively, of that record. The customer financial institution 
address is a telecommunications network directory number of the customer 
financial institution at which the customer financial institution is 
contactable and responds to an automatic interrogation and interchange as 
hereinafter described. 

Telepay TSN 30 has, as an optional feature, an ability to 
assure that the customer account has sufficient funds to cover the 
transaction amount prior to effecting the transaction. In this regard, and as 
indicated by step 314, customer fmancial institution interface 208-1 is 
directed to send the customer fmancial mstitution an authorization 
assurance request message. The authorization assurance request message is 
routed by customer financial institution in terface 208-1 over data network 
N to the customer financial institution address obtained at step 314. The 
authorization assurance request message, indicated as event E5 in Fig. 1, 
includes the transaction code, the customer account identifier, the 
transaction amount, and a message type code. The message type 
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specifically indicates that teiepay TSN 30 is seeking to determine whether 
the customer financial institution 80 will authorize a funds transfer fi-om the 
customer account in the amount of the transaction amount. Assuming 
authorization is granted, an authorization assurance message is transmitted 
5 over data network N by customer financial institution 80 to customer 
fmancial institution interface 208-1, as depicted by event E6 in Fig. 1. 

As indicated by step 316 of Fig. 3A, if the authorization 
assurance message is negative (indicating that authorization is not granted), 

10 an invalid transaction notification is sent to customer mobile station 60 (see 
step 318). Otherwise, as shown by step 320, the customer fmancial 
institution address and customer account identifier obtained fi-om step 306, 
along with an indication of receipt of a positive authorization assurance 
message, are stored in the record for the current transaction in transaction 

15 database 220. 

At step 322 the transfer coordination module 206 verifies that 
a valid merchant identifier was entered and determines the merchant 
fmancial institution address and the merchant account identifier at the 

20 merchant fmancial institution. In like manner as with step 306, at step 322 
the transfer coorttoation module 206 sends a signal to merchant search 
engine 208-4, the signal including the current transaction code and the 
current merchant identifier. Merchant search engine 208-4 searches 
merchant data base 224 for a record having the current merchant identifier 

25 in field 224A. Upon finding such a record, merchant search engine 208-4 
obtains the corresponding merchant financial institution address and the 
merchant account identifier from fields 224B and 224C, respectively, of 
that record. Then, merchant search engine 208-4 sends a signal to transfer 
coordination module 206 which includes the current transaction code, the 
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merchant identifier, and the merchant financial institution address and the 
merchant account identifier obtained fi-om the thusiy located record. 
Transfer coordination module 206 augments the record for the cun-ent 
transaction with the merchant financial institution address and the merchant 
5 account identifier (step 324). 

It is noted in passing, that should the merchant identifier not 
be found in data base 224 upon performance of step 322, an invalid 
transaction notification is sent to customer mobile station 60. Sunilarly, if 
10 the customer identifier were not located in customer data base 222 at step 
306, an invalid transaction notification would be sent to customer mobile 
station 60. 

At step 326, transfer coordination module 206 directs that a 
1 5 transaction verification request message be sent to customer mobile station 
60. In this regard, transfer coordination module 206 provides verification 
unit 202-4 with the current transaction code, the merchant identifier, and 
the transaction amount. Verification unit 202-4 in turn generates a 
verification request message which is transmitted to customer mobile 
20 station 60 and depicted as event E7 in Fig. 1 . Verification request message 
can take the form of an audible message or, when customer mobile station ' 
60 is suitably equipped, a digital display. The verification request message 
includes a prompt requestmg that the customer verify that the transaction is ^ 
to proceed. 

25 ■ • . 

If the customer agrees with the information provided m the 
transaction verification request message, the customer responds with an 
affirmative transaction verification message (as indicated by event E8 in 
Fig. 1). Step 328 shows receipt ofthe transaction verification message 
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from customer mobile station 60. Should it be determined at step 330 that 
the transaction verification message is negative, the transaction is 
invalidated and terminated as indicated by step 332. 

In like manner with step 326, at step 334 transfer 
coordination module 206 directs that a transaction verification request 
message be sent to merchant terminal 70. In this regard, transfer 
coordination module 206 provides verification unit 204-3 with the current 
transaction code, the merchant identifier, and the transaction amount. 
Verification unit 204-3 in turn generates a verification request message 
which is transmitted to merchant terminal 70 and depicted as event E9 in 
Fig. 1 . This verification request message preferably takes the form of a 
digital display at merchant terminal 70. The verification request message 
includes a prompt requesting that the merchant verify that die transaction is 
to proceed. If the merchant agrees with the information provided in the 
transaction verification request message, the customer responds with an 
affirmative transaction verification message (as indicated by event EIO in 
Fig. 1). Step 336 shows receipt of the transaction verification message 
from merchant terminal 70. Should it be determined at step 338 that the 
transaction verification message-is negative, the transaction is invalidated 
arid terminated as indicated by step 340. 

It should be understood that the merchant verification process 
of steps 334, 336, and 338 can be conducted before or essentially 
contemporaneous with the customer verification process of steps 326, 328, 
and 330. 

Alternatively, in one embodiment a transaction verification 
request message may be sent only to one party, e.g., to customer mobile 
station 60 and not to merchant terminal 70. 



wo 98/47116 



PCT/SE98/00691 



18 



Assuming that affirmative transaction verification messages 
are received both from the customer mobile station 60 and merchant 
terminal 70 in the embodiment currently described, transfer coordination 
module 206 is so apprised and, at step 342, updates the record for the 
current transaction to indicate verification by both parties. 

With the transaction approved by both parties, at step 344 
transfer coordination module 206 directs the funds transfer authorization 
module 210 to authorize initiation of transfer of the transaction amount 
from the customer accoimt to the merchant account. Along with this 
directive, funds transfer authorization module 2 1 0 is provided the 
transaction code, the transaction amount, the customer financial institution 
address, the customer account identifier, the merchant financial institution 
address, and the merchant account identifier. As indicated by event Ell in 
Fig. i, funds transfer authorization module 210 then signals the customer 
financial institution 80 over data network N with a funds transfer request 
message. The signal is sent using the customer financial institution 
interface 208-1 of fmancial institution communication module 208 (see Fig. 
2). The signal includes a message code type indicative of a funds transfer 
request, the. transaction code, the transaction amount,^ the customer financial 
institution address, the customer account identifier, the merchant fmancial 
institution address, and the merchant account identifier. 

Upon.authorizingjnitiation-otthefunds-transfer-,-at-step~346 

transfer coordination module 206 also directs that a transaction 
confumation message be sent to customer mobile station 60 (as event E12) 
and to merchant terminal 70 (as event E13). The transaction confirmation 
message is sent to customer mobile station 60 via transaction confirmation 
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unit 202-5 and to merchant terminal 70 via transaction confirmation unit 
204-4. 

Step 348 also shows transfer coordination module 206 
"sending-a-funds-transfer reque'stedTio^^ message to mercfiaSt 

financial institution 90 over data network N. The funds transfer requested 
notification message alerts institution 90 to expect to receive eventually a 
transfer of the transaction amount to the merchant account maintained at 
- merchant financial mstitution 90 from the customer financial institution 80. 
Such funds transfer requested notification message is depicted as event El 4 
in Fig. 1, 

Customer financial institution 80 can immediately transfer 
funds from the customer account to the merchant account at merchant 
financial institution 90, e.g., in accordance with usual banking procedures. 
For sake of simplicity, such transfer is depicted in Fig. 1 as event El 5. As 
an option, customer financial institution 80 can also send to telepay TSN 30 
a confirmation that the funds have been transferred from customer financial 
institution 80 to merchant financial institution 90. Merchant financial 
institution 90 in turn credits the merchant account with the transaction 
amount, which credit may ppssibly occur after a "float" delay. 

The system of Fig. lA differs from that of Fig. 1 e.g., in that 
customer mobile station 60 includes a GPS (global positionmg system) 
communication transponder 62. GPS transponder 62 serves to interrogate a 
GPS satellite 100 and to obtain therefrom a GPS response which indicates 
the current GPS coordinates of customer mobile station 60. Event EO of 
Fig. 1 A depicts interrogation and response of GPS satellite 100 by customer 
mobile station 60. GPS interrogation and response can occur periodically 
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during activation of customer mobile station 60. Alternatively, customer 
mobile station 60 can be programmed to interrogate GPS satellite 100 upon 
detection of the dialing of the digits of the telepayment service of the 
present invention. 

5 

The current GPS location coordinates of customer mobile 
station 60 are transmitted to telepay SCP 30 and received by information 
collector 202-3 of customer communication module 202. Transmission of 
the current GPS location coordinates can occur in number of ways. For 

10 example, upon completion of call connection prompt generator 202 may 
issue a tone which is recognized by customer mobile station 60 as requiring 
customer mobile station 60 to send the current GPS location coordinates of 
customer mobile station 60 to telepay TSN 30. Alternatively, upon 
completion of call connection, the customer mobile station 60 may (on its 

15 own initiative) transmit its current GPS location coordinates at a 

predetermined time. Regardless of timing and maimer of transmission, the 
transmission of the current GPS location coordinates is governed by the 
protocol between customer mobile station 60 and telepay TSN 30. 

20 Fig. 2 A( 1 ) shows an embodiment of telepay TSN 

30A(1 )suitable for the first mode of the invention, i.e., the mode illustrated 
in Fig. 5A in which the customer's mobile station is proximate the 
merchant's premises. The telepay TSN 30A(1) of Fig. 2A(1) resembles 
that of Fig. 2 but in addition includes transaction security module 212A. 
Furth er, m erchant data base 224 of Fig. 2 D contains an addit ional field for 
each merchant record, particularly a field 224D. Field 224D has prestored 
therein the merchant location (GPS) coordinates. 



For telepay TSN 30A(1) of Fig. 2A(1), an additional field of 
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information is obtained at step 306, particularly the merchant location 
coordinates of field 224D. In performance of its operations, telepay SCP 
30 otherwise executes steps similar to those shown in Fig. 3A, Fig. 3B, and 
Fig. 3C. In addition, telepay TSN 30A(1) executes the steps shown in Fig. 

At step 3 08 A of Fig. 4A, transaction security module checks 
whether customer mobile station 60 is within a predetermined geographical 
proximity of merchant terminal 70. In particular, transfer communication 

10 . module 206 passes to transaction security module 212 the merchant GPS 
location coordinates obtained at step 306 and the current GPS coordinates 
of customer mobile station 60. Transaction security module 212 then 
compares the merchant GPS location coordinates obtained at step 306 and ^ 
the current GPS coordinates of customer mobile station 60. If the two sets 

15 of coordinates are not within an acceptable proximity range, transaction 
security module 2 12A issues a signal to transfer communication module 
206 indicating that the transaction should be invalidated. Transfer 
communication module 206 responds by notifying the customer of 
transaction invalidity and by terminating the transaction (step 3 lOA). On 

20 the other hand, if the two sets of coordinates are within an acceptable 
proximity .range, transaction security module 212A issues a signal to 
transfer communication module 206 indicating that the transaction is valid. 
Transfer communication module 206 then proceeds to the next step, e.g., 
step 314 of Fig. 3 A. 

25 

.. Thus, in the embodiment described in Fig. lA and Fig. 2A(1), 
telepay TSN 30 confirms that customer mobile station 60 is within a 
predetermined geographical proximity of merchant terminal 70 prior to 
requesting transfer of the transaction amount fi:om the customer account to 
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the merchant account of the merchant financial institution. The 
geographical proximity check is a safeguard which precludes purchases 
unless the customer is actually physically present at the merchant's place of 
business. 

Fig. 2A(2) shows an embodiment of telepay TSN 
30A(l)suitable for the second mode of the invention, i.e., the mode 
illustrated in Fig. 5B and in Fig. 5C in which the customer's mobile station 
is at customer's predetermined native location. The telepay TSN 30A(2) of 
Fig. 2A(2) resembles that of Fig. 2 but in addition includes transaction 
security module 212B. Further, customer data base 222 of Fig. 2A(2) 
contains an additional field for each customer record, particularly a field 
222D. Field 222D has prestored therein one or more sets of customer 
location (GPS) coordinates, e.g., the coordinates of thecustomo-'s 
predetermined native locatioii(s)i5 '^ - - , - , ; 

For telepay TSN 30A(2) of Fig. 2A(2), an additional field of 
information is obtained at step 306, particularly the customer location 
coordinates of field 222D. In performance of its operations, telepay SCP 
30A(2) otherwise executes steps similar to those shown in Fig; 3 A, Fig. 3B, 
and Fig. 3C. In-addition, telepay TSN 30A(2) executes the steps shown in 
Fig.4B-.''-- ■ 

At step 308B ofFig. 4B, transaction security module checks 

whether giKitMnCTjmobile^station_60^^ 

proximity of a registered customer predetermined native location. In 
particular, transfer communication module 206 passes to transaction 
security module 212 the customer GPS location coordinates obtained at 
step 306 and the current GPS coordinates of customer mobile station 60. 
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Transaction security module 2 12 then compares the customer GPS location 
coordinates obtained at step 306 and the current GPS coordinates of 
customer mobile station 60. If the two sets of coordinates are not within an 
acceptable proximity range, transaction security modu le 2 12B issues a 
5 signal to transfer communication module 206 indicating that the transaction 
should be invalidated. Transfer communication module 206 responds by 
notifying the customer of transaction invalidity and by terminating die 
transaction (step 310B). On the other hand, if the two sets of coordmates 
are within an acceptable proximity range, transaction security module 212 

0 issues a signal to transfer communication module 206 indicating thafrthe 
transaction is valid. Transfer communication module 206 then proceeds to 
the next step, e.g., step 314 of Fig. 3 A. 

Thus, in the embodiment described in Fig. 1 A and Fig. 2A(2), 
5 telepay TSN 30 confirms that customer mobile station 60 is within a 
predetermined geographical proximity of one of the customer's 
predetermined native locations prior to requesting transfer of the 
transaction amount from the customer account to the merchant account of 
the merchant financial instimtion. The geographical proximity check is a 

1 safeguard which precludes purchases unless the customer is actually 
physically present at a location which the customer has previously 
registered with telepay TSN 30. 

While the Fig. lA and Fig. 2A(1)/2A(2) embodiment of the 
invention requires customer presence and/or predetermined location as a 
security feature, the presence of a credit card or check is not required for 
the transaction. The only equipment required is the customer mobile 
station 60. In one embodiment, the invention requires that the customer 
also know a customer account identifier (PIN) in order to effect the 
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transaction with a measure of security. 

Security based on geographic proximity can also be 
accomplished in ways other than using GPS technology. For example, 
5 geographic location of customer mobile station 60 can be accomplished 
using very accurate clocks and measuring the radio propagation times for 
the mobile signal relative to different radio base stations. As another 
simple but less accurate example, TSN 30 can mterrogate the mobile 
network subscriber database (e.g, a home location register [HLR] in GSM) 

1 0 to inquire as to which MSC and which radio base station is handling the 
customer's mobile station 60 to determine where customer mobile station 
60 is located. Upon receipt of a response to the interrogation, the returned 
information, being indicative of the geographical location of customer 
mobile station 60, is compared with the pre-stored location of merchant 

15 terminal 70. 

In the foregoing embodiments, telepay TSN 30 has been 
described as a special purpose node which serves as a termination point for 
. call connection from the customer's mobile station 60. In such 
20 embodiments, no protocol is employed between MSC 54 and telepay TSN - 
, 30, Moreover, telepay TSN 30 includes (or has connected thereto) the 
intelligent peripheral SOP. 

The embodiment of telepay node 30' shown in Fig. IB, on the 
25 other hand, is not a special pur pose node but rather a ser vice control point 
(SCP) of an intelligent network. In the embodiment of Fig. 1, a call made 
from the customer's mobile station 60 is terminated at mobile switching 
center (MSC) 54. MSC 54 includes certain service switching function 
software which enables MSC 54 to function like a service switching point 



wo 98/47116 



PCT/SE98/00691 



25 

(SSP). Upon reception of the call from the customer's mobile station 60, 
MSC 54 signals with telepay TSN 30' using INAP (Intelligent Network 
Application Part protocol) over CCITT signaling system No. 7. For this 
reason, what was shown in Fig. 1 as a single event E2 is shown in Fig. IB 
as event E2A (call connection from customer mobile station 60 to MSC 54) 
and event E2B (signaling from MSC 54 to telepay TSN 30'). 

Thus, the embodiment of Fig. IB differs from those 
previously described in that MSC 54 serves as the call connection node, 
and communication between MSC 54 and telepay TSN 30' occurs by 
signaling. Such being the case, in the embodiment of Fig. IB, no 
intelligent peripheiral 30P is provided at telepay TSN 30, but is instead 
moved to MSC 54 where it appears as peripheral 54P. When prompts such 
as tone and/or voice prompts are directed by telepay TSN 30' as is indicated 
by event E3 A, such directives are transmitted by signaling to MSC 54, and 
then to intelligent peripheral 54P. Intelligent peripheral 54P then generates 
the prompts for application (e.g., event E3B) to the intended recipient e.g., 
mobile station 60. Similarly, intelligent peripheral 54P interprets any 
DTMF tones inputted by the customer (e.g., PIN) at event E4A, whereupon 
the interpreted information (e.g., PIN) is signaled as event E4B from MSC 
54 to telepay TSR30'. Although not expressly shown in Fig., IB, it should 
be understood that subsequent communications with customer mobile 
station 60, as well as merchant teminal 70 (e.g., verification and response), 
are accomplished using signaling between MSC 54 and telepay TSN 30'. 

The embodiment of Fig. IB is also optionally implemented 
using the above-described security features, such as GPS, for example. 
Such implementation is readily ascertained from the preceding discussions. 
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Whereas the embodiments of Fig. 1 and Fig. lA are simple 
and perhaps less expensive to implement in low traffic situations, the 
embodiment of Fig. IB has greater capacity and scalability. 

All embodiments herein described can be realized on a 
general computer with UNIX or Windows NT, or other general purpose 
operating system based on special purpose computers, such as the Ericsson 
APZ Telecom Purpose Computer, for example. For implementation in a 
European country, for example, the telepay TSN nodes can communicate ir 
MAP protocol to the GSM HLR database, over signaling no. 7 (SS7) or 
TCP/IP, for example. 

t The present invention can be enhanced using encryption 

techniques for communications between telepay TSN 30 on the one hand 
an customer mobile station 60 and merchant terminal 70 on the other. 
Encryption can be accomplished, for example, using a SIM (subscriber 
identification mobile) card in customer mobile station 60 and a similar 
encryption card at customer terminal 70. - 

Further, the SIM (subscriber identification mobile) card 
utilized by customer moWle«tation 60 of the present invention can also- « 
serve as a credit card, in which case payment can be debited to the 
customer's credit card account or telephone bill. In this regard, the SIM 
card has the customer's account number stored therein, which account 

number can be auto matically_communicated-by-customer-mQbile-station 

unit 60 to telepay TSN 30. For example, telepay TSN 30 can issue a 
special interrogation (e.g., a message in the signaling link to the mobile 
station or a tone) to customer mobile station unit 60 which is detected and 
interpreted by the SIM card, and to which tfie SIM card causes station 60 to 
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respond automatically with the customer's account stored in the SIM card. 
In the case of such prestorage of customer account information in a SIM 
card, there need be no look up at telepay TSN 30 for the customer's 
account number, A database look up process can be utilized to determme a 
"liefworlcaddress foTtHeTmanciarinstitution which administers the account. 
Telepay TSN 30 can then provide the transaction amount and customer 
account number to the financial institution, whereupon the financial 
institution prepares an appropriate statement (e.g., credit card statement or 
telephone bill) which includes the transaction amount. 

Prompts utilized by telepay TSN 30, such as those for entry 
of data (e.g., transaction amount, merchant identifier) and verification, can 
utilize short message, service features for the display of text on telephones 
and terminals having suitable display units. For short message service 
(SMS), telepay TSN 30 signals either a SMS server (provided in GSM or 
equivalent systems) or the home location register (HLR). Alternatively, in 
an intelligent network environment, telepay TSN 30' can signal a SCP, 
which in turn can signal the SMS server or HLR, which in turn signal the 
MSG 54 for contacting the mobile station or terminal. 

In some embodiments the customer line identity (e.g., calling 
party's directory number) is used as the customer's billing number, or 
alternatively is used to look up (in a database) an account number 
corresponding to the customer line identity. In most modem networks such 
as ISDN, the customer line identity (CLI) is signaled all the way through to 
the end user equipment, thereby facilitating such services as Calling Line 
Identification ("Caller ID"). Accordingly, one implementation for debiting 
the mobile customer is to get the CLI directly if an appropriate signaling 
protocol is used to telepay TSN 30 (for TSN 30 not being an SCP-type 
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node). If telepay TSN 30 is a SCP-type node, the SSP obtains the mobile 
number (CLI) via the networic signaling (e.g., ISUP or TUP protocols 
according to ITU standards) and sends the CLI to the SCP via the INAP 
protocol. Thus, telepay TSN 30 does not have to interrogate the customer 
5 mobile unit 60 for its account number. 

In addition to the security features described above, a 
protocol specific to each mobile standard on top of signaling no. 7 interface 
(or TCPIP or X.25) to mobile network can be employed to connect to 

10 . different databases that can give useful information on the mobile handset 
and its owner, i.e. whether the handset is a valid subscriber, if it has been 
reported stolen, which radio cells its signal is received by, signal strength 
and cell locations (in GSM e.g. Home Location Register, Equipment 
Identity Register, Authentication Centre). This information can also be 

15 used as data to validate the transaction e.g. a stolen handset can not pay 
for purchases, and a handset can not verify a purchase; in. a shop in New 
York if the radio cell to which it is connected is in San Francisco. 

In the embodiments of Fig. 5B and Fig. 5C, the merchant's 
20 web page is generated and transmitted by a web server 7 1 (which may, or 
may not,,be at the merchant' s premises). The mechanics of Web page 
generation and transmission is not germane to the present invention. 
Standard internet protocols and security funtionality can be employed. The 
information conveyed on the Web page is pertinent, in that such 
!5 information either presents or enables the customer to acq ui re financ ial 
information in the nature of e.g., an advertisement or a bill. The 
advertisement may provide a description of a product or service, as well as 
a cost (transaction amount) and a merchant identifier, and perhaps a 
ti-ansaction code or tiie like to identify the particular advertised item or bill 
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(invoice) number or account number. 

As one example, in the manner illustrated in Fig. 5B, at home 
a customer on computer 64 may reach the Web page of a utility company in 
5 order to pay, for example, a utility bill. By entering the customer's name or 
account number with the utility company (and possibly a PIN or the like for 
security reasons), the customer is linked to a display of the customer's 
present utility bill. The display provides the transaction amount (current 
balance due), as well as a merchant identifier and possibly a transaction 

10 code. The customer then dials the Telepay TSN number using the 

customer's mobile station 60, and in response to prompts enters e.g., the 
merchant identifier and transaction amount (and possibly the transaction 
code). If the customer is situated at one of the customer's predetermined 
native locations, the transaction is completed in the manner described 

15 herein. 

In the embodiment of Fig. 5C, both internet access and access 
to Telepay TSN 30 are accomplished using mobile station 60 in the form of 
laptop computer 60 with mobile termination. In this embodiment, laptop 
20 computer 60 and the mobile network are capable of having multiple 
connections between the network and a mobile station. 

The present invention thus facilitates funds transfer for 
payment of goods and/or services without use of a credit card, bank check 
25 or the like; is essentially immediate, simple, and secure. 

While the invention has been particularly shown and 
described with reference to the preferred embodiments thereof, it will be 
understood by those skilled in the art that various alterations in form and 
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detail may be made therein without departing from the spirit and scope of 
the invention. 
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WHAT IS C LAIMED TS; 



1 LA method of facilitating automated payment from a customer 

J account of a customer financial institution to a merchant account of a 

3 merchant financial institution, the method including: 

4 acquiring a merchant identifier and transaction amount from a 

5 customer mobile station; 

6 verifying the transaction amount with a merchant terminal; and 

7 upon receipt of a verification from the merchant terminal, requesting 

8 transfer of the transaction amount from the customer account to the 

9 merchant account. 

1 2. The method of claim 1, further comprising consulting a customer 

2 data base wherein is stored for the customer ( 1 ) a telecommunications 

3 address of the customer financial institution and (2) a customer account 

4 identifier. 



1 3 . The method of claim 1 , further comprising consulting a merchant 

2 data base wherein is stored for the merchant identifier ( 1) a 

3 telecommunications address of the merchant fmancial institution and (2) a 

4 merchant account identifier, 

1 4. The method of claim 1, further comprising determining whether 

2 the customer mobile station and the merchant terminal are within a 

3 predetermined geographical proximity, and wherein transfer of the 

4 transaction amount from the customer account to the merchant account is 

5 precluded unless the customer mobile station and the merchant terminal are 

6 within the predetermined geographical proximity. 



wo 98/47116 



PCT/SE98/00691 



32 

1 5. The method of claim 4 further comprising obtaining geographic 

2 coordinates of the customer mobile station, and comparing the geographic 

3 coordinates of the customer mobile station with geographic coordmates of 

4 the merchant terminal to determine whether the customer mobile station 

5 and the merchant terminal are within the predetermined geographical 

6 proximity. 



1 6. The method of claim 1, further comprising determining whether 

2 the customer mobile station is situated at a customer predetermined native 
location, wherein transfer of the transaction amount from the customer 

4 account to the merchant account is precluded unless the customer mobile 

5 station is at the customer predetermined native location. 



3 



1 



1 



1 



7. The method of claim 1 , wherein the merchant identifier 



2 acquired from a display on a computer screen. 



8. The method of claim 7, wherein the merchant identifier 



IS 



is 



2 acquired from a web page. 



9. The method of claim 1, wherem the merchant identifier is 
acquired from a .display on a computer screen, the computer screen being 



3 situated at a customer predetermined native location. 



10. the method of claim 9, further comprising determining whether 

2 the customer mobile st ation is situated at the customer predetermined native 

3 location, wherein transfer of the transaction amount from the customer 

4 account to the merchant account is precluded unless the customer mobile 

5 station is at the customer predetermined native location. 
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1 11. The method of claim 1 , further comprising teiephonically 

2 interfacing with a data base at the customer financial institution to 

3 determine whether debiting of the customer account by the transaction 

4 amount is authorized. 



1 



5 



12. A method for facilitating automated funds transfer of a 
transaction amount, the method comprising: 

determining, at a service node of a telecommunications network, 



4 whether: (1) a customer mobile station and a merchant terminal are within 

5 a predetermined geographical proximity; or (2) the customer mobile station 

6 is situated at a customer predetermined native location; and 

7 in response to the determining, arranging, at the service node and in 

8 response to a request from the customer mobile station, transfer of the 

9 transaction amount from a customer account of the customer financial 
10 institution to a merchant account of the merchant financial institution. 

1 13. The method of claim 12, further comprising using a merchant 

2 identifier provided on a display on a computer screen for ascertaining the 

3 merchant account. 



14. The method of claim 13, wherein the merchant identifier is 



2 acquired from a web page. 



1 1 5 . A method for facilitating automated funds transfer of a 

2 transaction amount, the method comprising: 

3 determining, at a service node of a telecommunications network, 

4 whether: (1) a customer mobile station and a merchant terminal are within 
a predetermined geographical proximity; (2) the customer mobile station is 

6 situated at a customer predetermined native location; and 
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7 in response to the determining, arranging, at the service node and in 

8 response to request from the customer mobile station, for a credit message 

9 to be sent to a merchant account of the merchant financial institution and a 

10 debit message to be sent to a customer account of the customer financial 

1 1 institution. 



1 16. The method of claim 1 5 , further comprising using a merchant 

2 identifier provided on a display on a computer screen for ascertaining the 

3 merchant account. 

1 17. The method of claim 16, wherein the merchant identifier is 

2 acquired fi^om a web page. 

1 1 8 . A telecommunications service for facilitating funds transfer of a 

2 transaction amount, the service comprising: 

3 a customer mobile station; 

4 a merchant terminal; 

5 a customer financial institution; 

6 a merchant financial institution; 

7 a service node which, in response to a request from the customer 

8 , . mobile station, arranges for transfer of the transaction amount from a 

9 customer account of the customer financial institution to a merchant 

10 account of the merchant financial institution provided that the service node 

1 1 determines at least one of the following: (1) that the customer mobile 
station and the merchant terminal are wit hin a predetermined geographical 

13 proximity; and (2) that the customer mobile station is situated at a 

1 4 customer predetermined native location; and 

15 a mobile switching center connected to the service node, to the 

1 6 customer mobile station, and to the merchant terminal; and, 



wo 98/47116 



PCT/SE98/00691 



35 

1 7 a data network which connects the service node to the customer 

18 financial institution and to the merchant financial institution 

19. The system of claim 18, further comprising usin g a merchant 

2 identifier provided on a display on a computer screen for ascertaining the 

3 merchant account. 

1 20. The system of claim 1 9, wherein the merchant identifier is 

2 acquired fi-om a web page. 

1 2 1 . A service node of a telecommunications network which, in 

2 response to a request from a customer mobile station, arranges for transfer 

3 of a transaction amount from a customer account of the customer financial 

4 institution to a merchant account of merchant financial institution provided 

5 that the service node determines that the customer mobUe station and the 

6 merchant terminal are within a predetermined geographical proximity 

1 22. A service node of a telecommunications network which, in 

2 response to a request from a customer mobile station, arranges for transfer 

3 of a transaction amount from a customer account of the customer financial 

4 institution to a merph^t account of merchant financial institution provided 

5 that the service node determines that the customer mobile station is at a 

6 customer predetermined native location 

1 23. A telecommunications service for facilitating funds transfer of a 

2 transaction amount, the service comprising: 

3 a customer mobile station which includes a subscriber identification 

4 mobile card, the subscriber identification mobile card having stored therein ' 

5 a customer account number; 
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6 a merchant terminal; 

7 a customer financial institution; 

8 a merchant financial institution; 

9 a service node which, upon receiving a call fi"om the customer 

10 mobile station: 

11 (1) acquires a merchant identifier, transaction amount, and the 

12 customer account number from the customer mobile station; 

13 (2) verifies the transaction amount with at least one of the customer 

14 mobile station and the merchant terminal; and 

15 (3) upon receipt of a verification, requests 

16 crediting of the transaction amount to a merchant account of the 

17 merchant financial institution and debiting of the transaction amount to the 

18 customer account; 

19 a mobile switching center connected to the service node, to the 

20 customer mobile station, and to the merchant terminal; and, 

21 a data network which connects the service node to the customer 

22 financial mstitution and to the merchant financial institution 



1 24. The service of claim 23, wherein the customer account number 

2 is one of a customer credit card account or a customer telephone bill 

3 account. - 

1 25. The service of claim 23, fiirther comprising using information 

2 obtained on a display on a computer screen as the merchant identifier 

_3 — provided-and-for-aseertaining-the-merchant-account; 



I 

2 



26. The system of claim 25, wherein the information is acquired 
from a web page. 
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1 27. A telecommunications service for facilitating funds transfer of a 

2 transaction amount, the service comprising: 

3 a customer mobile station; 

4 a merchant terminal; 

5 a customer financial institution; 

6 a merchant financial institution; 

7 a service node which, in response to a call fi-om the customer mobile 

8 station: 

(1) acquires a merchant identifier and transaction amount fi-om the 
customer mobile station; 

(2) verifies the transaction amount with the merchant terminal; and 

(3) upon receipt of a verification, requests transfer of the transaction 
amount from the customer account to a merchant account of the merchant 
financial institution; and 

a mobile switching center connected to the service node, to the 
customer mobile station, and to the merchant terminal; and, 

a data network which connects the service node to the customer 
financial institution and to the merchant financial institution 

28. The apparatus of claim 27, wherein the service node determines 
whether the customer mobile station and the merchant terminal are within a 
predetermined geographical proximity prior to requesting transfer of the 
transaction amount from the customer account to the merchant account of 
the merchant financial institution. 

29. The apparatus of claim 28, ftjrther wherein the service node 
obtains geographic coordinates of the customer mobile station, and wherein 
the service node compares the geographic coordinates of the customer 
mobile station with geographic coordinates of the merchant terminal to 
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5 determine whether the customer mobile station and the merchant terminal 

6 are within a predetermined geographical proximity 

1 30. The apparatus of claim 27, further comprising a transaction 

2 security module which determines whether the customer mobile station is 

3 situated at a customer predetermined native location, and wherein transfer 

4 of the transaction amount from the customer account to the merchant 

5 account is precluded unless the customer mobile station is at the customer 

6 predetermined native location. 

1 31. The apparatus of claim 27, further comprising a customer data 

2 base wherein is stored for the customer (1) a telecommunications address of 

3 the customer financial institution and (2) a customer account identifier. " 



1 32. The apparatus of claim 27, further comprising a merchant data 

2 base wherein is stored for the merchant identifier (1) a telecommunications 

3 address of the merchant financial institution and (2) a merchant account 

4 identifier. 

1 33. The apparatus of claim 27, wherein the service node 

2 communicates with the customer financial institution to determine whether 

3 debiting of a customer account by the transaction amount is authorized. 

1 34. The apparatus of claim 33, wherein information ascertained 

2 from a display on a computer screen is u sed as the merchant identifier 

1 35. The apparatus of claim 34, wherein the information is acquired 

2 from a web page. 
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36. A node of a telecommunications network which facilitates 
payment from a customer account of a customer financial institution to a 
merchant account of a merchant financial institution, the node comprising: 

a customer communication module which requires a merchant 
identifier and transaction amount from a customer mobile station; 

a merchant communication module which verifies the transaction 
amount with a merchant terminal; and 

a funds transfer authorization module which, upon receipt by the 
merchant communication module of a verification from the merchant 
terminal, requests transfer of the transaction amoum from the customer 
account to the merchant account, 

, 37. The apparatus of claim 36, wherein the node is a service control 
point of an intelligent telecommunications network. 

38. The apparatus of claim 36, wherein the node is a special 
fimction node. 

39. The apparatus of claim 36, further comprising a customer data 
base wherein is stored for the customer (1) a telecommunications address of 
the customer financial institution and (2) a customer account identifier, r . 

40. The apparatus of claim 36, fiirther comprising a merchant data 
base wherein is stored for the merchant idemifier (1) a telecommunications 
address of the merchant financial institution and (2) a merchant account 
identifier. 



41 . The apparatus of claim 36. further comprising a transaction 
security module which determines whether the customer mobile station and 
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the merchant terminal are within a predetermined geographical proximity, 
and wherein transfer of the transaction amount from the customer account 
to the merchant account is precluded unless the customer mobile station 
and the merchant terminal are within the predetermined geographical 
proximity. 

42. The apparatus of claim 41 , wherein the transaction security 
module obtains geographic coordinates of the customer mobile station, and 
wherein the transaction security module compares the geographic 
coordinates of the customer mobile station with geographic coordinates of 
the merchant terminal to determine whether the customer mobile station 
and the merchant terminal are within the predetermined geographical 
proximity. > 

43. The apparatus of claim 36, further comprising a transaction 
security module which determines whether the customer mobile station is 
situated at a customer predetermined native location, and wherein transfer 
of the transaction amount from the customer account to the merchant 
account is precluded unless the customer mobile station is at the customer 
predetermined native location. 

44. The apparatus of claim 36, further comprising a financial 
institution module which communicates with the customer financial 
institution to determine whether debiting of the customer account by the 
transaction_amount-is-authorized — ~~ 
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